fix: issue where when the status is set to away, the app does not ring and no join btn is visible [WPB-22834]#5018
Conversation
MohamadJaara
requested review from
Garzas,
Copilot and
saleniuk
and removed request for
Copilot
Codecov Report❌ Patch coverage is ❌ Your patch check has failed because the patch coverage (74.62%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## develop #5018 +/- ##
===========================================
+ Coverage 49.35% 49.40% +0.05%
===========================================
Files 653 653
Lines 23543 23598 +55
Branches 3621 3625 +4
===========================================
+ Hits 11619 11659 +40
- Misses 10848 10861 +13
- Partials 1076 1078 +2
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
MohamadJaara
changed the title
There was a problem hiding this comment.
Pull request overview
This PR updates the Android app’s conversation list/search and call UI to derive “ongoing/joinable call” indicators from Kalium’s in-memory joinable-calls observation, rather than relying on persisted conversation call-state fields. This aligns with the breaking Kalium model change and targets the reported issue where calls aren’t surfaced correctly (e.g., missing join UI) when the user status is set to Away.
Changes:
- Inject and consume
ObserveJoinableCallsUseCasein conversation list/search flows to drive join-call markers and related ordering signals. - Update
ConversationDetailsWithEvents.toConversationItem()mapping to computehasOnGoingCall/“new activities” from the joinable-calls map. - Adjust DI wiring and unit tests to accommodate removal of model call-state fields and the new joinable-calls source.
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| app/src/test/kotlin/com/wire/android/ui/home/conversationslist/ConversationListViewModelTest.kt | Mocks ObserveJoinableCallsUseCase to support updated conversation list ViewModel dependencies. |
| app/src/test/kotlin/com/wire/android/ui/home/conversations/usecase/GetConversationsFromSearchUseCaseTest.kt | Adds coverage ensuring joinable calls produce an ongoing-call marker in search results. |
| app/src/test/kotlin/com/wire/android/ui/home/conversations/details/updateappsaccess/UpdateAppsAccessViewModelTest.kt | Removes usage of the deleted hasOngoingCall model field in test fixtures. |
| app/src/test/kotlin/com/wire/android/ui/home/conversations/details/GroupDetailsViewModelTest.kt | Removes usage of the deleted hasOngoingCall model field in test fixtures. |
| app/src/test/kotlin/com/wire/android/ui/home/conversations/composer/MessageComposerViewModelArrangement.kt | Updates mocked conversation details to no longer require hasOngoingCall. |
| app/src/test/kotlin/com/wire/android/ui/home/conversations/call/ConversationCallViewModelTest.kt | Switches call-state observation in tests from ongoing calls list to joinable calls map. |
| app/src/main/kotlin/com/wire/android/ui/home/HomeViewModelFactory.kt | Wires ObserveJoinableCallsUseCase into conversation list/search-related construction. |
| app/src/main/kotlin/com/wire/android/ui/home/conversationslist/ConversationListViewModel.kt | Combines conversation list details with joinable calls to build UI items with join-call markers. |
| app/src/main/kotlin/com/wire/android/ui/home/conversations/usecase/GetConversationsFromSearchUseCase.kt | Combines paginated search results with joinable calls to map items with call markers. |
| app/src/main/kotlin/com/wire/android/ui/home/conversations/call/ConversationCallViewModel.kt | Uses joinable calls map to derive hasOngoingCall state for the conversation call screen. |
| app/src/main/kotlin/com/wire/android/ui/calling/CallingViewModelFactory.kt | Updates factory wiring to provide ObserveJoinableCallsUseCase to ConversationCallViewModel. |
| app/src/main/kotlin/com/wire/android/mapper/ConversationMapper.kt | Adds joinable-calls map input and derives call marker/new-activity signals from it. |
| app/src/main/kotlin/com/wire/android/di/accountScoped/CallsModule.kt | Exposes ObserveJoinableCallsUseCase from CallsScope for injection. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…mprove query logic
MohamadJaara
force-pushed
the
mo/refactor/get-calls-status-from-in-memory
branch
from
3e87592 to
1e6574c
Compare
| ): Flow<PagingData<ConversationItem>> = channelFlow { | ||
| val latestJoinableCallsByConversationId = MutableStateFlow(initialJoinableCallsByConversationId) |
There was a problem hiding this comment.
Do we need channelFlow and MutableStateFlow here? It looks like only one coroutine calls send(), and the MutableStateFlow seems to be used just to keep the latest value rather than as a reactive stream.
There was a problem hiding this comment.
Good catch We still need to collect joinableCallsFlow concurrently because PagingData.map is lazy and newly loaded pages should use the latest call state without call changes reemitting the same PagingData. However, you’re right that only one coroutine emits and the MutableStateFlow is only being used as a latest-value holder. I’ll simplify this to a regular flow with a child collector and use an AtomicReference for the thread-safe snapshot.
|
https://wearezeta.atlassian.net/browse/WPB-22834
Data Flow
flowchart LR AVS["AVS call events"] CallRepo["CallRepository"] Memory["In-memory calls map<br/>ConversationId -> Call"] DB["Call DB writes<br/>(kept for existing consumers)"] Ordering["Conversation list/search ordering"] AppUI["Android conversation UI<br/>join button / row marker"] AVS --> CallRepo CallRepo --> Memory CallRepo --> DB Memory --> Ordering Memory --> AppUIWhy
Conversation list state should not depend on persisted calling rows or session-init reset work. Keeping active AVS call state in memory avoids DB pressure during Kalium init and gives consumers faster
ConversationId -> Calllookup.Breaking Change
Removed call-state fields from public Kalium conversation models:
ConversationDetails.Group.hasOngoingCallConversationDetailsWithEvents.hasOngoingCallConsumers should derive join-call UI from call APIs / the in-memory joinable-call map instead.